Cette session d'introduction va au-delà du chaos culture « enregistrer sous » pour définir les systèmes de contrôle de version (VCS) comme des outils spécialisés pour la gestion des modifications. Nous examinons la transition depuis une duplication manuelle et primitive des fichiers — illustrée par des objets comme mon-travail-de-fin-2.doc—vers des systèmes structurés qui traitent l'historique comme une série de captures logiques.
1. Le piège des suffixes
Avant l'arrivée des VCS formels, le contrôle de version était un processus manuel et sujet aux erreurs impliquant des conventions de renommage de fichiers (par exemple, ajouter des dates ou des balises « final »). Cela conduit inévitablement à entropie des fichiers et à la perte de données car l'utilisateur est seul responsable de se souvenir des différences entre les fichiers.
2. Captures structurelles
Les premières tentatives d'organisation impliquaient la méthode « pile de dossiers »—déplacer manuellement les fichiers du projet dans une hiérarchie verticale étiquetée v1.0, v2.0 et v2.1. Bien qu'elle fournisse un historique chronologique, elle manque de intégrité atomique et de traçabilité.